Every quality engineer has a version of the same monthly ritual: pull the scrap report, notice the numbers don’t tie to what the line reported, and spend a day and a half figuring out why “Defect_Code_7” on Line 3 means something different than “DefectCode07” on Line 4, and why the rework loop on the new filler doesn’t show up as rework at all — it just looks like extra cycle time. Multiply that by however many lines feed your MES quality module, and you’ve got a standing tax on every close-out cycle.
The frustrating part is that the infrastructure to prevent this has been sitting there the whole time. OPC UA has supported structured, extensible information modeling since its earliest releases, and the companion specifications published in the years since — plus the newer OPC UA FX work aimed at machine-to-machine interoperability — give you real tools for expressing what a scrap event, a defect code, or a rework loop actually is, not just where its value lives in a register. Most plants never use them that way. They stand up an OPC UA server, get the security certificates and encryption sorted, expose a flat pile of tags, and call the integration done. The semantics — the part that makes scrap data mean the same thing everywhere — gets left for someone downstream to sort out by hand.
Why connectivity-first integration breaks quality rollups
OPC UA’s security model (certificate-based authentication, signed and encrypted sessions per IEC 62443 guidance) gets a lot of attention because auditors ask about it directly. Nobody audits whether your defect taxonomy is normalized. So teams optimize for what gets checked. The result is a namespace that’s secure and browsable but semantically flat: a folder of tags per machine, each with a plain string or integer value, no formal type, no relationship to an ISA-95 quality object, and no shared vocabulary across lines from different OEMs or different automation vintages.
MES quality modules — whether you’re running a major MES platform’s native quality module or a custom SQL-backed reporting layer — generally expect scrap and rework data to arrive already shaped: a defined defect code from a governed list, tied to a specific operation and material genealogy record, with a disposition (scrap, rework, use-as-is, return-to-vendor) that maps to a known state machine. When the PLC layer hands over unstructured tags instead, someone in quality becomes the translation layer. That’s manual, it’s error-prone, and it doesn’t scale past a handful of lines.
Model quality data as objects, not tags
The fix starts with treating OPC UA’s object-oriented modeling capability as the actual point, not a formality. A few concrete moves:
- Define a DefectEvent object type. Instead of exposing a raw integer for “defect code,” model a structured object type with properties for defect code (from a governed enumeration), operation/work center reference, timestamp, detected-by (operator, vision system, gauge), and severity. Give it a stable NodeId structure and reuse the same type definition across every line, regardless of PLC vendor.
- Use enumerations, not free-text or raw integers, for defect and disposition codes. OPC UA supports typed enumerations with human-readable EnumStrings. If Line 3’s PLC logic assigns defect code 7 and Line 4’s assigns a different meaning to the same integer, no amount of downstream mapping fixes that cleanly — you’re patching a modeling gap with ETL logic that breaks every time someone adds a code.
- Model rework as a loop, not a side note. Rework is where most namespace designs quietly fail. A part that fails, gets reworked, and passes on a second pass needs to preserve that history — not just show final good count. Structure a ReworkEvent type that references the originating DefectEvent, records the rework operation performed, and links back to the same unit or lot ID so genealogy survives the round trip. If your current model only increments a “rework counter” tag with no linkage to the original defect, you have a rollup that will never reconcile against ISA-95-style genealogy records.
- Align your object types to ISA-95 Part 2/Part 4 quality and production data models where they already define the shape you need — segment response data, production performance, and quality test results all have established structures. You don’t have to reinvent the schema; you have to stop skipping it.
Namespace mapping is where good intentions die
Even a well-designed information model falls apart if your namespace mapping into MES is done ad hoc. A few practical rules:
- Assign a dedicated namespace URI per logical model (your DefectEvent types, your rework types) rather than letting everything live under a vendor’s default namespace — that’s what makes the model portable across PLC platforms as lines get replaced or added.
- Version your companion information model deliberately. When a new defect code gets added six months from now, it should extend the existing type, not force a redefinition that breaks every existing MES mapping.
- Push governance of the defect and disposition code list up to quality engineering, not down to whoever’s configuring the PLC that week. The taxonomy should be defined once, centrally, and referenced — not re-typed line by line.
A checklist before your next line adds a defect code
Before that next SKU launch or line retrofit adds “just one more” scrap reason, audit what you already have:
- Pull every existing OPC UA node currently feeding scrap or rework data into MES. Are they typed objects or raw scalar tags?
- Check whether defect codes are enumerated with shared meaning across lines, or whether each PLC program invented its own numbering.
- Trace one rework event end to end. Can you follow it from the original defect through the rework operation to final disposition without a spreadsheet lookup?
- Confirm your namespace URIs are stable and documented, not defaulted to whatever the PLC vendor’s engineering tool assigned.
- Compare your current model against the ISA-95 quality and production segment structures — not to copy them verbatim, but to catch where your model is missing a relationship (operation link, genealogy link, disposition state) that ISA-95 already accounts for.
- Ask quality engineering, not just controls engineering, to sign off on the defect taxonomy before it’s built into firmware or PLC logic. Once it’s baked into ladder logic, changing it is a change-management project, not a config edit.
None of this replaces the security and connectivity work — that’s still necessary and still worth doing right. But it’s not sufficient. The plants that get clean, trustworthy scrap reports without a week of manual reconciliation are the ones that treated the information model as the actual deliverable, not the plumbing around it. As OPC UA FX and companion spec adoption keeps accelerating plant-floor rollouts this year, the gap between “connected” and “semantically usable” is exactly where quality teams keep losing their time. Close that gap once, at the model level, and it stays closed through the next line expansion instead of reopening every time someone adds a defect code.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
